How a NAT Works

Today, network address translators, or NATs, are everywhere. Their ubiquitous adoption was not promoted by design or planning but by the continued growth of the Internet, which places an ever-increasing demand not only on IP address space but also on other functional requirements that network address translation is perceived to facilitate. This article presents a personal perspective on the history of NATs, their pros and cons in a retrospective light, and the lessons we can learn from the NAT experience. A Retrospective View of Network Address Translation ZHANG LAYOUT 9/5/08 1:03 PM Page 8 Authorized licensed use limited to: IEEE Xplore. Downloaded on February 9, 2009 at 17:52 from IEEE Xplore. Restrictions apply. IEEE Network • September/October 2008 9 public IP destination address D located in the global Internet, the packet is routed to N . N translates the private source IP address in P’s header to N’s public IP address and adds an entry to its internal table that keeps track of the mapping between the internal host and the outgoing packet. This entry represents a piece of state, which enables subsequent packet exchanges between H and D. For example, when D sends a packet P’ in response to P, P’ arrives at N, and N can find the corresponding entry from its mapping table and replace the destination IP address — which is its own public IP address — with the real destination address H, so that P’ will be delivered to H. The mapping entry times out after a certain period of idleness that is typically set to a vendor-specific value. In the process of changing the IP address carried in the IP header of each passing packet, a NAT box also must recalculate the IP header checksum, as well as the checksum of the transport protocol if it is calculated based on the IP address, as is the case for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) checksums. From this brief description, it is easy to see the major benefit of a NAT: one can connect a large number of hosts to the global Internet by using a single public IP address. A number of other benefits of NATs also became clear over time, which I will discuss in more detail later. At the same time, a number of drawbacks to NATs also can be identified immediately. First and foremost, the NAT changed the end-to-end communication model of the Internet architecture in a fundamental way: instead of allowing any host to talk directly to any other host on the Internet, the hosts behind a NAT must go through the NAT to reach others, and all communications through a NAT box must be initiated by an internal host to set up the mapping entries on the NAT. In addition, because ongoing data exchange depends on the mapping entry kept at the NAT box, the box represents a single point of failure: if the NAT box crashes, it could lose all the existing state, and the data exchange between all of the internal and external hosts must be restarted. This is in contrast to the original goal of IP of delivering packets to their destinations, as long as any physical connectivity exists between the source and destination hosts. Furthermore, because a NAT alters the IP addresses carried in a packet, all protocols that are dependent on IP addresses are affected. In certain cases, such as TCP checksum, which includes IP addresses in the calculation, the NAT box can hide the address change by recalculating the TCP checksum when forwarding a packet. For some of the other protocols that make direct use of IP addresses, such as IPSec [7], the protocols can no longer operate on the end-to-end basis as originally designed; for some application protocols, for example, File Transfer Protocol (FTP) [8], that embed IP addresses in the application data, application-level gateways are required to handle the IP address rewrite. As discussed later, NAT also introduced other drawbacks that surfaced only recently. A Recall of the History of NATs I started my Ph.D. studies in the networking area at the Massachusetts Institute of Technology at the same time as RFC 791 [9], the Internet Protocol Specification, was published in September 1981. Thus I was fortunate to witness the fascinating unfolding of this new system called the Internet. During the next ten years, the Internet grew rapidly. RFC 1287 [2], Towards the Future Internet Architecture, was published in 1991 and was probably the first RFC that raised a concern about IP address space exhaustion in the foreseeable future. RFC 1287 also discussed three possible directions to extend IP address space. The first one pointed to a direction similar to current NATs: Replace the 32-bit field with a field of the same size but with a different meaning. Instead of being globally unique, it would be unique only within some smaller region. Gateways on the boundary would rewrite the address as the packet crossed the boundary. RFC 1335 [3], published shortly after RFC 1287, provided a more elaborate description of the use of internal IP addresses (i.e., private IP addresses) as a solution to IP address exhaustion. The first article describing the NAT idea, “Extending the IP Internet through Address Reuse” [10], appeared in the January 1993 issue of ACM Computer Communication Review and was published a year later as RFC 1631 [11]. Although these RFCs can be considered forerunners in the development of NAT, as explained later, for various reasons the IETF did not take action to standardize NAT. The invention of the Web further accelerated Internet growth in the early 1990s. The explosive growth underlined the urgency to take action toward solving both the routing scalability and the address shortage problems. The IETF took several follow-up steps, which eventually led to the launch of the IPng development effort. I believe that the expectation at the time was to develop a new IP within a few years, followed by a quick deployment. However, the actual deployment during the next ten years took a rather unexpected path. The Planned Solution As pointed out in RFC 1287, the continued growth of the Internet exposed strains on the original design of the Internet architecture, the two most urgent of which were routing system scalability and the exhaustion of IP address space. Because long-term solutions require a long lead time to develop and deploy, efforts began to develop both a short term and a long-term solution to those problems. Classless inter-domain routing, or CIDR, was proposed as a short term solution. CIDR removed the class boundaries embedded in the IP address structure, thus enabling more efficient address allocation, which helped extend the lifetime of IP address space. CIDR also facilitated routing aggregation, which slowed down the growth of the routing table size. However, as stated in RFC 1481 [12], IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling: “This strategy (CIDR) presumes that a suitable long-term solution is being addressed within the Internet technical community.” Indeed, a number of new IETF working groups started in late 1992 and aimed at developing a new IP as a long-term solution; the Internet Engineering Steering Group (IESG) set up a new IPng area in 1993 to coordinate the efforts, and the IPng Working Group (later renamed to IPv6) was established in the fall of 1994 to develop a new version of IP [13]. CIDR was rolled out quickly, which effectively slowed the growth of the global Internet routing table. Because it is a quick fix, CIDR did not address emerging issues in routing scalability, in particular the issue of site multihoming. A multihomed site should be reachable through any of its multiple provider networks. In the existing routing architecture, this requirement translates to having the prefix, or prefixes, of the site listed in the global routing table, thereby rendering provider-based prefix aggregation ineffective. Interested readers are referred to [14] for a more detailed description on multihoming and its impact on routing scalability. The new IP development effort, on the other hand, took much longer than anyone expected when the effort first ZHANG LAYOUT 9/5/08 1:03 PM Page 9 Authorized licensed use limited to: IEEE Xplore. Downloaded on February 9, 2009 at 17:52 from IEEE Xplore. Restrictions apply. IEEE Network • September/October 2008 10 began. The IPv6 working group finally completed all of the protocol development effort in 2007, 13 years after its establishment. The IPv6 deployment also is slow in coming. Until recently, there were relatively few IPv6 trial deployments; there is no known commercial user site that uses IPv6 as the primary protocol for its Internet connectivity. If one day someone writes an Internet protocol development history, it would be very interesting to look back and understand the major reasons for the slow development and adoption of IPv6. But even without doing any research, one could say with confidence that NATs played a major role in meeting the IP address requirement that arose out of the Internet growth and at least deferred the demand for a new IP to provide the much needed address space to enable the continued growth of the Internet. The Unplanned Reality Although largely unexpected, NATs have played a major role in facilitating the explosive growth of Internet access. Nowadays, it is common to see multiple computers, or even multiple LANs, in a single home. It would be unthinkable for every home to obtain an IP address block, however small it may be, from its network service provider. Instead, a common implementation for home networking is to install a NAT box that connects one home network or multiple home networks to a local provider. Similarly, most enterprise networks deploy NATs as well. It also is well known that countries with large populations, such as India and China, have most of their hosts behind NAT boxes; the same is true for countries that connected to the Internet only recently. Without NATs, the IPv4 address space would have been exhausted a long time ago. For reasons discussed later, the IETF did not standardize NAT implementation or operations. However, despite the lack of standards, NATs were implemented by multiple vendors, and the deployment spread like wildfire. This is because NATs have several attractions, as we describe next.